System and method for committing and rolling back database requests

ABSTRACT

Systems, methods, and computer-readable storage media for processing database requests on a database hosted on a stateless, non-persistent computing environment are provided. A server stores database requests to insert update or delete data in a unit of work set identified by a unique code. The database requests are performed on the database upon receiving an instruction to commit the database requests to the database. If an instruction is sent to rollback a unit of work set the database remains unchanged. This allows a client to handle requests in logical groups.

BACKGROUND 1. Technical Field

The present disclosure relates to a system and method for processingdatabase requests by a remote server and, more specifically, torecording database requests in unit of work (UOW) sets and performingthe database requests in the unit of work set after the unit of work setis closed.

2. Introduction

A system and method are disclosed which allows a user computing device(a “client”) accessing a database located on a remote server to commitor rollback a set of database requests in NoSQL computing environments.The commit/rollback feature is a known method of database managementthat is used when editing standard query language (SQL) databases. Intraditional SQL databases, modifications are not applied to the databaseuntil the modifications are expressly committed. Instead, themodifications are stored in a temporary location until a commitinstruction is received. It is not until after the instruction isreceived that the modifications are performed on the database. Thus, themodifications performed since the last commitment may easily be undoneby submitting a rollback instruction to the database. If rollbackinstruction is submitted, the data remains unchanged and themodifications discarded. This is also advantageous because modificationsmay be undone if a session times-out or fails. Here, the system is ableto group transactions from a client because the client device connectsto the server or storage device hosting the database and maintains thatconnection until the client choses to terminate it. Thus, all databaserequests received via the connection can be easily grouped together andstored in a temporary location until a commit or rollback instruction isreceived.

However, NoSQL environments are stateless and non-persistent by nature,thus the transport mechanism does not allow commit/rollback. BecauseNoSQL is stateless and non-persistent, the transport mechanism does notallow for commit/rollback features. The cloud may be one example of aNoSQL remote server based computing environment. The cloud is defined ashaving five characteristics: on-demand service; broad network access bystandard client mechanisms (mobile phones, laptops, tablets, andworkstations); dynamic demand-based assignment of provider resourcepooling; elastically provisioned and released capabilities; and resourceusage measuring and monitoring. Cloud and other shared storage computingsystems are often non-persistent and stateless. Hosting a database in astateless non-persistent environment advantageously allows the server todynamically allocate access to the database in response to user demand.It also allows multiple users to access the database simultaneously.

Because these systems are non-persistent and stateless, a clientconnects with the server housing the database when the database requestis initiated. After the database is accessed and the database requestprocessed, the connection between the client and the server isterminated. If the user wants to make additional edits to the database,the client initiates a new connection. Thus, the traditionalcommit/rollback function cannot operate in this technical environment.Embodiments of the invention solve the technical problem of allowingcommit/rollback functions in a stateless or non-persistent computersystem.

SUMMARY

Additional features and advantages of the disclosure will be set forthin the description that follows, and in part will be obvious from thedescription, or can be learned by practice of the herein disclosedprinciples. The features and advantages of the disclosure can berealized and obtained by means of the instruments and combinationsparticularly pointed out in the appended claims. These and otherfeatures of the disclosure will become more fully apparent from thefollowing description and appended claims, or can be learned by thepractice of the principles set forth herein.

A data storage system disclosed herein may comprise: one or more remotecomputer-readable storage mediums configured to form a non-persistentstateless connection with a client; one or more processors; a databasehosted on the one or more remote computer-readable storage mediums; theone or more remote computer-readable storage mediums having instructionsstored which, when executed by the processor, cause the one or morecomputer-readable storage mediums to perform actions comprising:generating a unit of work token containing a unique identification codeand one or more parameters; recording the unit of work token in a unitof work repository; generating a unit of work set associated with theunit of work token; returning the unit of work token to the client;receiving one or more database requests from the client, the databaserequests including the unit of work token; recording the databaserequests in the unit of work set; and committing or rolling-back thedatabase requests in the unit of work set based on an instruction tocommit or rollback the unit of work set.

A computer-readable storage medium disclosed herein may storeinstructions which, when executed by a computing device, cause thecomputing device to perform a method comprising: generating a unit ofwork set with a unique identification code; sending the uniqueidentification code to a client with a non-persistent statelessconnection with the computer-readable storage medium; receiving two ormore database requests having the unique identification code from two ormore HTTP sessions; recording the two or more database requests in aunit of work set; and committing the two or more database requests inthe unit of work set or rolling-back the two or more database requestsin the unit of work set after the unit of work set is closed.

A method for processing database requests on a database hosted on astateless non-persistent computing environment disclosed herein maycomprise of: generating a unique identification code to identify a unitof work set; generating the unit of work set at a storage location andassigning one or more parameters to the unit of work set; receiving, bya remote server, database requests from a client and recording thedatabase requests in the unit of work set; closing the unit of work setbased the one or more parameters assigned to the unit of work set; anddetermining whether to perform the database requests in the unit of workset on the database after the unit of work set is closed.

Disclosed are systems, methods, and non-transitory computer-readablestorage media for committing and rolling-back database requests on aNoSQL server. The disclosed system and method groups database requestsinto unit of work sets. The database requests are then committed to thedatabase or rolled-back from the database as a unit upon receiving aninstruction from the client.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary computer system;

FIG. 2 illustrates an example process flow for recording and processingunit of work sets;

FIG. 3 illustrates an exemplary method of recording, committing, androlling-back an insert request;

FIG. 4 illustrates an exemplary method of recording, committing, androlling-back a delete request;

FIG. 5 illustrates an exemplary method of recording, committing, androlling-back an update request; and

FIG. 6 illustrates an example method embodiment operating on computersystems.

DETAILED DESCRIPTION

Embodiments of the present invention extract and group multiple datapackets coming from a client computer into unit of work sets. The unitof work sets that can be committed or rolled-back as a logical unit. Thelogical unit, called a unit of work set, includes multiple data packetsthat may instruct to modify a database (“database requests”) that arestored in a unit of work repository. The grouped data packets areassociated with a unique identification code so that they can beidentified on the remote unit of work repository and recorded in theunit of work set with the corresponding unique identification code. Thisarrangement and association of specific data packets allows the databaserequests to be grouped in a logical set even when the database requestsare sent over multiple sessions of connectivity. As noted above,embodiments of the invention solve the technical problem in stateless ornon-persistent computer systems of committing or rolling back databaseactions.

Embodiments of the invention are advantageous particularly inclient-server computing environments that use request-response typeprotocols such as HTTP. Request-response protocol can be used either tocreate a connection between client computers and server computers thatpersists so that multiple requests can be sent in a single session. Theprotocol can also be non-persistent such that the connection between theclient and server is formed when the request is sent and the connectionis terminated when the request is completed. Embodiments of theinvention solve the technical problem of the commit-rollback featureoperating in non-persistent connections by identifying the databasemodification requests (“database requests”) with a unique identificationcode assigned to that set of database requests. The uniqueidentification code may be assigned to a client by a remote server sothat multiple clients accessing the database receive unique codes toidentify discrete units of work. This allows multiple clients to makemodifications to the database simultaneously.

In one embodiment, the unit of work set is committed or rolled-backautomatically in response to a connection timeout or failure. Otherembodiments commit or rollback unit of work sets after a duration oftime has passed since the unit of work set was initiated, or when thenumber of records in a unit of work set exceeds a threshold. In someembodiments, a system automatically creates a new unit of work set afterthe previous unit of work set is committed or rolled-back so that thecommitment or rollback is done periodically and continuously whileaccessing the database. Embodiments of the invention allows operationsin NoSQL environments or other stateless, non-persistent environments,to commit or rollback large groups of database modifications, preservingdatabase integrity and increasing the ease at which a user can undomistaken modifications or incomplete modifications. Embodiments of theinvention provide a new system, data associations, and data structuresthat overcome the problems of conventional systems.

For example, a client may initiate a unit of work set by firstrequesting a unique identification code. The code is used to identify aset of database requests (the “unit of work set”) from the client. Thedatabase requests may include commands to insert, update (i.e. changethe value), or delete data from the database. The unique identificationcode is generated and returned to the client. In applications wheremultiple clients access the database, the unique identification code maybe generated by a remote server accessible by the multiple clients. Theunique identification code may also be generated locally. In thisexample, the unique identification code will be referred to as “UID1.”Next, the client determines whether the forthcoming database requests inthe unit of work set should be committed to the database or rolled-back.Some embodiments may rollback all non-committed requests by default.This may be advantageous so that partial edits to the database that arenot completed due to a time-out or connection failure are not made tothe database. In other embodiments, this may advantageously preventchanges to the database unless the client expressly choses to commit thechanges, this may advantageously prevent edits made in error fromeffecting the database. To commit the database requests the client cancreate a token with the unique identification code and the commitinstruction, such as:

(UID1, commit).

The token may also include a set of parameters further discussed below.To rollback the forthcoming set of database requests, the client maycreate a token with the unique identification code and a rollbackinstruction, such as:

(UID1, rollback).

The client then sends the token to a unit of work repository forrecording unit of work sets. The unit of work repository creates anempty set identified by the unit of work's unique identification codeand containing the instruction, for example:

(UID1, commit)::[ ].

The client may then submit database requests to the unit of workrepository to be recorded in the unit of work set. In statelessnon-persistent computing environments, the client sends a request toconnect to a port on the server hosting the unit of work repository. Theserver may instruct the client to form a connection to the server via adynamically assigned port. When a connection is formed between theclient and the server, the server receives the database request from theclient. The database request may include the unique identification code,a command, and a value. For example, if the command is to insert thevalue “1000” at a location1 in the database, the database request may bein the form:

[UID1, insert, location1, 1000].

“[L]ocation1” may be an actual location or a pointer to a location onthe database. The unit of work repository then searches for the unit ofwork set with UID in its header. Upon locating the corresponding unit ofwork set, the unit of work repository adds the content of the databaserequest to the unit of work set. The resulting exemplary unit of workset reads:

(UID1, commit)[(insert, location1, 1000)].

In stateless non-persistent computing environments, the connectionbetween the client and the server is terminated after the databaserequest is received.

To send additional database requests to the unit of work set, the clientcan send a new request to connect to the server. The resultingconnection may be at different port than the initial connection. Afterforming the connection, the client can send the additional databaserequest. For example, the client may send a command to update the valueat location2 to “2000,” such a request may read:

[UID1, update, location2, 2000].

The unit of work repository again searches for a unit of work set withthe heading containing UID and adds the contents of the second databaserequest to the unit of work set so that the unit of work set reads:

(UID1, commit)::[(insert, location1, 1000), (update, location2, 2000)].

If the unit of work repository receives a third database request, suchas (UID1, delete, location3) the process repeats so that the unit ofwork set reads:

(UID1, commit)::[(insert, location1, 1000), (update, location2, 2000),(delete, location3)].

The unit of work set may be closed by any of the methods discussedbelow. When the unit of work set is closed (or no longer “live”) noadditional database may be added to that unit of work set. At thatpoint, the unit of work repository evaluates the token to determinewhether to commit or rollback the database requests in the unit of workset. In this example, the instruction is to commit the databaserequests. The instruction may also be to rollback the database requestsin the unit of work set. If the instruction is to commit, the unit ofwork repository sends the database the content of the database requestsin the unit of work set. The database is modified in accordance with thedatabase requests. In this example, “1000” is inserted at location1, thevalue at location2 is changed from its current value to “2000”, and thevalue at location3 is deleted. If, instead, the token indicated that thedatabase requests were to be rolled-back (such that the token insteadread (UID1, rollback)) the modifications are not performed on thedatabase and the database is unchanged by the database requests in theunit of work set.

In some embodiments, the database may be a key-value database. In theseembodiments, the location of the data may be stored in a key store.Thus, in the above example, the client may send the database a commandto insert “1000” at location1 as (UID, insert, key1, 1000). If, asdescribed above, the unit of work repository is instructed to commit theunit of work containing request (UID1, insert, key1, 1000), the keystore will be sent the key “key1.” The key store may have various keyspaired to locations in the database, for example:

[key1, location1]

[key2, location2]

[key3, location3]

The location associated with the key is retrieved and the command isperformed at the location on the database associated with the key. Inthe above example, the key store searches for key1 and returns thelocation (or location pointer) location1 and inserts “1000” at thatlocation.

U.S. Patent Application No. 2015/0302037 discloses a NoSQL, key/valuestore database that operates in a cloud-computing environment. Thedisclosed database is hosted on a web-based remote server accessible bymultiple users from multiple remote locations. Users can send databaserequest to insert, delete, or update the database using a keyidentifying the data to be inserted, deleted, or updated. The keys arepaired with location pointers pointing to the location of the data onthe database and the pairing is stored in a key store. For example, if auser sends an update request, the new data is stored at a location andthe location pointer paired with the key is changed to reflect the newlocation of the data. The old data may then be deleted. When a usersends an insert requests, the new data is added to the database and thelocation is sent to the key store to generate a location pointer pairedwith a key identifying the new data. The key may be generatedautomatically or created by the user. When a user sends a deleterequest, the data is removed from the database and the key and locationpointer are removed from the key store.

In some embodiments, users may be prevented from accessing data that hasnot yet been committed to the database or data that may be subject to arollback. In these embodiments, a key store notes that the data is beingaltered so that other users may be prevented from accessing the datastored at the location while the key is the subject of a databaserequest in a live unit of work set. This advantageously prevents a userfrom altering data that may not be current or overriding more recentdata values.

The disclosed system may include two or more computer systems includingthe client device and a server. With reference to FIG. 1, an exemplarycomputer system includes a general-purpose computing device 100,including a processing unit (CPU or processor) 120 and a system bus 110that couples various system components including the system memory 130such as read only memory (ROM) 140 and random access memory (RAM) 150 tothe processor 120. The computing device 100 can include a cache ofhigh-speed memory connected directly with, in close proximity to, orintegrated as part of the processor 120. The computing device 100 copiesdata from the memory 130 and/or the storage device 160 to the cache forquick access by the processor 120. In this way, the cache provides aperformance boost that avoids processor 120 delays while waiting fordata. These and other modules can control or be configured to controlthe processor 120 to perform various actions including initiating aconnection with a remote computing device and modifying information onthat device. Other system memory 130 may be available for use as well.The memory 130 can include multiple different types of memory withdifferent performance characteristics. It can be appreciated that thedisclosure may operate on computing devices like computing device 100with more than one processor 120 or on a group or cluster of computingdevices networked together to provide greater processing capability. Theprocessor 120 can include any general purpose processor and a hardwaremodule or software module, such as module 1 162, module 2 164, andmodule 3 166 stored in storage device 160, configured to control theprocessor 120 as well as a special-purpose processor where softwareinstructions are incorporated into the actual processor design. One suchmodule may be an application programming interface (API) for controllingcommunications between various software components and computer devices.The processor 120 may essentially be a completely self-containedcomputing system, containing multiple cores or processors, a bus, memorycontroller, cache, etc. A multi-core processor may be symmetric orasymmetric.

The system bus 110 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. A basicinput/output (BIOS) stored in ROM 140 or the like, may provide the basicroutine that helps to transfer information between elements within thecomputing device 100, such as during start-up. The computing device 100further includes storage devices 160 such as a hard disk drive, amagnetic disk drive, an optical disk drive, tape drive or the like. Thestorage device 160 can include software modules 162, 164, 166 forcontrolling the processor 120. Other hardware or software modules arecontemplated. The storage device 160 is connected to the system bus 110by a drive interface. The drives and the associated computer-readablestorage media provide nonvolatile storage of computer-readableinstructions, data structures, program modules and other data for thecomputing device 100. In one aspect, a hardware module that performs aparticular request includes the software component stored in a tangiblecomputer-readable storage medium in connection with the necessaryhardware components, such as the processor 120, bus 110, display 170,and so forth, to carry out the request. In another aspect, the systemcan use a processor and computer-readable storage medium to storeinstructions which, when executed by the processor, cause the processorto perform a method or other specific actions. The basic components andappropriate variations are contemplated depending on the type of device,such as whether the computing device 100 is a small, handheld computingdevice, a desktop computer, or a computer server.

Although the exemplary embodiment described herein employs the hard disktype storage device 160, other types of computer-readable media whichcan store data that are accessible by a computer, such as magneticcassettes, flash memory cards, digital versatile disks, cartridges,random access memories (RAMs) 150, and read only memory (ROM) 140, mayalso be used in the exemplary operating environment. Tangiblecomputer-readable storage media, computer-readable storage devices, orcomputer-readable memory devices, expressly exclude media such astransitory waves, energy, carrier signals, electromagnetic waves, andsignals per se.

To enable user interaction with the computing device 100, an inputdevice 190 represents any number of input mechanisms, such as amicrophone for speech, a touch-sensitive screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 170 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems enable a user to provide multiple types of input to communicatewith the computing device 100. The communications interface 180generally governs and manages the user input and system output. There isno restriction on operating on any particular hardware arrangement andtherefore the basic features here may easily be substituted for improvedhardware or firmware arrangements as they are developed.

FIG. 2 discloses an example process flow for processing and recordingunit of works sets on a computer system. Here, a client seeking to makemodifications on a remotely hosted database requests a token thatuniquely identifies a unit of work set for the modifications. The clientrequests a unit of work token at step 200. The token request is receivedby a processing device that could include any remote computer-readablemedium including the server hosting the database or an applicationprogram interface that negotiates the interactions between the serverand the client. At 202 a unique identifying service generates a uniqueidentification code (UID) unique to the unit of work set and returns thecode to the requesting device. At 204 the processing device generates aunit of work token that includes the unique identification code. Theunit of work token may also include a number of parameters that indicatehow the unit of work is to be handled. In some embodiments unit of workset parameters may be provided by the client in the token request. Inother embodiments, the user may be prompted to provide parameters or theparameters may be automatically assigned to the unit of work token. Infurther embodiments, the unit of work token may include informationpointing to the parameter locations. The parameters may be used todynamically configure the unit of work set.

Examples of the parameters may include a maximum number of databaserequests that may be assigned to the unit of work set and/or an amountof time a unit of work set may remain live. Other embodiments may haveparameters that additionally or alternatively include a designatordesignating if a unit of work set may be viewed before it is committedto the database and/or an instruction on how to handle the unit of workset when the unit of work set is closed. Additional parameters are alsocontemplated.

The unit of work token is then returned to the client. At 206 the unitof work set is created in a unit of work repository that may be locatedon the database or other remote server. A live flag may be set for theunit of work set that indicates that other requests may be added to theunit of work set. A clock may also start to monitor how long the unit ofwork token has been live at 208.

At 210 the client sends a database request to edit the database. Thismay include modifications to a value in the database, adding an entry tothe database, deleting an entry in the database, or other databasetransactions. The database request may include a key associated with thedatabase entry that the user is seeking to modify, the type of commandthat the user seeks to perform, and the unit of work token. If thecommand is an insert or update command the database request may alsocontain the data be added to the database. At 210 the database requestis sent to the unit of work repository. At 212 the database reads thetoken, identifies which unit of work set to assign the database request,and records the database request in the unit of work set.

The key may be sent to a key store to retrieve a location pointer of thedata to be inserted, updated or deleted and the location pointer may bestored in the unit of work repository. In other embodiments, the unit ofwork set may record the key but not the location pointer. While the unitof work set is live all database requests from a client are recorded inthe unit of work set. At 214 the system determines whether the unit ofwork set is live. The process will return to 210 when it receives a newdatabase request while the unit of work set is live.

There are a number of ways the system may determine whether the unit ofwork set is live at 214. In some embodiments, unit of work setparameters may include a duration threshold. The threshold may beincluded in the unit of work token. If the token includes a durationthreshold, the clock that was initiated at 208 may be compared to theduration threshold. If the clock exceeds the threshold, it is determinedthat the unit of work set is no longer live and the unit of work set isclosed. The parameters might also indicate a maximum number of recordsthat can be assigned to a unit of work set and if the number of recordsin the unit of work set exceeds the threshold, the unit of work set isclosed. For example, the unit of work repository may count the number ofentries recorded in a set and signal to the application programinterface when the set has closed and a new unit of work token isissued. Similarly a clock monitoring the time a unit of work token hasbeen active may be compared to a duration indicated in the unit of workparameter and may signal the application program interface and unit ofwork repository to close the unit of work set and issue a new token. Aclient may also send an instruction to close a set. The instruction mayadditionally include an instruction to commit or rollback the unit ofwork set. The client may also request a new unit of work token manually.When the unit of work is closed, the live flag may be removed at 216.

At 218 the system evaluates the unit of work token or user instructionto determine whether the unit of work set will be committed orrolled-back. If the unit of work token indicates that the unit of workset should be committed to the database, the database requests areperformed on the database. No action is taken on the database if theunit of work token or user instruction indicates that the unit of workset should be rolled-back, thus the requests are rolled back at 222. Inother embodiments, the application programming interface or the servermay prompt the user to instruct the system to commit or rollback thedatabase requests in the unit of work set upon closing the unit of workset. If it is determined that the database requests are to be performedon the database, the database requests in the unit of work set arecommitted at 220. In other embodiments, the system may automaticallyrequest a new unit of work token and return to 200. In furtherembodiments, the system may send an error to the client if a requestwith the unit of work token is received after the unit of work set itclosed. The error may additionally prompt the user to provide aninstruction to commit or rollback the closed unit of work set. Thus,clients will be able to commit or rollback multiple database requests atone time that were made over a number of different HTTP sessions.

Additionally, the parameters may include an instruction allowing orprohibiting other clients to view or edit data that is the subject ofdatabase requests that has not been committed. The parameters may alsoinclude instructions to delete the database requests in the unit of workset upon a decision to rollback the requests. It may further includeinstructions to delete the database requests in the unit of work setafter they have been performed on the database. In an embodiment, theunit of work repository may be instructed to delete a unit of work setan duration of time after they have been committed or rolled-back. Thismay include a general instruction to delete the unit of work sets aftera predetermined time or after a time specified by the parameters of theset. Unit of work sets may also be deleted when the unit of workrepository has reached capacity or a given file size.

In key/value database embodiments, the system may allow or prohibitother clients from viewing or editing data that is the object of anon-committed database request. In these embodiments, the key associatedwith the location pointer may be flagged when a database request is sentthat effects the data at that location. The flag may be removed from thedata implicated by the database requests in a unit of work set when theset is closed after the rollback has been completed or after thedatabase requests in the unit of work set have been committed to thedatabase.

FIG. 3 shows an exemplary method of recording, performing, androlling-back an update request. At 300 the client requests a unit ofwork token via an application programming interface. The unit of worktoken is returned from the application programming interface at 302 witha unique identification code and parameters indicating a duration oftime that the unit of work token may remain live, a maximum number ofrecords that may be recorded in the unit of work set, and an instructionto commit or rollback the unit of work set database requests when theunit of work set is closed. In some embodiments the client may indicatethe parameters for the unit of work token. In other embodiments theapplication programming interface may include default parameters in theunit of work token or prompt the client to send parameters for the unitof work token. At 304 the unit of work set is initialized in a unit ofwork repository. At 306 the client submits an insert request including akey and a data value to the unit of work repository. At 308 the unit ofwork repository sends a request to the database to add data to thedatabase and the data is added to the database at a location. Thelocation may be dynamically determined based on the location ofavailable storage on the database. At 310 a pointer to the data locationstoring the data is returned to the unit of work repository. At 312 arecord is created in the unit of work repository in the live unit ofwork set including the key and the pointer to the location of the dataon the database, the repository may additionally record the data. At 314the key and location pointer are added to the key store and anon-committed flag is set in the key store for the key. Thenon-committed flag may prohibit other users from accessing the data. Forexample, a user searching for values assigned to the key may receive a404 error while the non-committed flag is set. At 316 the set is closedand the commit or rollback instruction is retrieved from the unit ofwork token at 318. At 320 the unit of work record is read by theprocessor. If the token for the unit of work set indicates that thedatabase requests contained therein should be committed, thenon-committed flag is removed at 322. The data may then be retrieved byany user with the proper credentials using the key. If the token for theunit of work indicates that the database request contained thereinshould be rolled-back at 320 the location pointer for the data isretrieved from the key store at 324 and the data at that location isdeleted from the database at 326. In other embodiments, the locationpointer may be recorded in the unit of work set in the unit of workrepository and accessed from the repository directly at 324. After thedata is deleted the key entry (including the key, location pointer, andnon-committed flag) is deleted from the key-store at 328. The record,commit, and rollback method for an insert request explained above mayalso be performed with a delete or update request.

FIG. 4 shows exemplary method of recording, performing, and rolling-backa delete request. At 400 a unique identification service receives arequest for a unique identification code via an application programminginterface. The unit of work token is generated at 402 with the uniqueidentification code and parameters for handling the unit of work setassigned to the unique identification code. At 404 a unit of work set iscreated in a unit of work repository identified by the unit of worktoken. At 406 the system receives a delete request from a clientincluding a key for the data to be deleted and the unit of work token.At 408 the location pointer to the data paired with the key is retrievedfrom the key store and a non-committed flag is set in the key store forthe key at 410. At 412 the repository finds a live unit of work set andcreates a record in the unit of work set including the key and locationpointer. The process is repeated for every database request having theunit of work token. At 414 the set is closed and the system may promptthe user to issue a commit or rollback instruction. In otherembodiments, the system may receive an instruction to close and a commitor rollback to a live key set. In other embodiments, the instruction maybe retrieved from the token.

If the instruction received at 416 indicates that the database requestsshould be committed, the system retrieves the location pointer from theunit of work repository and the location pointer is retrieved at 418. At420 the data is removed from the database. At 422 the key, locationpointer, and non-committed flag is removed from the key store. If theinstruction received at 416 is to rollback the database requests thenon-committed flag is deleted from the key store at 424. In otherembodiments, the data may be deleted from the database before the unitof work is closed and the data stored in the unit of work set in theunit of work repository. In these embodiments, the system retrieves thelocation pointer and data and inserts the data back in to the locationindicated by the location pointer if instructed to rollback the unit ofwork set. The process is repeated for every database request in the unitof work set. The record, commit, and rollback method for a deleterequest explained above may also be performed for an insert or updaterequest.

FIG. 5 shows an exemplary method of recording, performing, androlling-back an update request. At 500 the client requests a unit ofwork token via an application programming interface. An applicationprogramming interface requests a unique identification code and returnsthe unique identification code to the client at 502. At 504 the clientgenerates a unit of work token with the unique identification code tosend to a unit of work repository. At 506 a unit of work set is createdin a unit of work repository. At 508 the client submits an updaterequest including a key and a new data value to the database that isreceived by the unit of work repository and key store. The system thenlocates the unit of work set identified by the unique identificationcode in the unit of work repository. In some embodiments, the process at500 may be initiated by the receipt of a database request. At 510 thekey and new data are recorded in the unit of work set in the unit ofwork repository with the unique identification code. At 512 the datalocation pointer paired to the key in the key store is retrieved andrecorded to the unit of work set. At 514 the systems retrieves the dataat the location pointer and records it to the unit of work set. At 516the system identifies an empty location on the database and a locationpointer to the new data location is recorded in the unit of work set. Insome embodiments, the data location pointer may be included in the keystore with a new key at 516 and the new key is recorded in the unit ofwork set. A non-committed flag may additionally be set in the key storefor the key and the new key. Additional insert, update, and deleterequests may be performed and recorded in the unit of work set until theunit of work set is closed at 518. The unit of work set may be closed inaccordance with any of the embodiments described herein. At 518 thesystem determines whether to commit or rollback the unit of work set. Ifthe system determines that the data is to be committed, the new datawill be written to the database at the new data location at 520. At 522the new location is written to the key store and paired with the key. At524 the old location pointer and key entry is deleted from the keystore. If the system is instructed to rollback the unit of work set, thenon-committed flag is removed from the key store at 526. The commit orrollback is performed on data in the unit of work set.

As described above, the data may be inserted and deleted before or afterthe unit of work set is closed and the commit or rollback performed. Inembodiments that add or delete the data before the unit of work set isclosed and committed or rolled-back, the data and location pointer arerecorded in the unit of work set while it is live. When a rollback isperformed, deleted data will be written back on the database andinserted data will be deleted.

FIG. 6 shows an example of a client committing and rolling-back data. Aclient 602 may be any type of computer storage device connected to anetwork. The client is connected to an application programming interface604. At 606 the client sends a unit of work token request to theapplication programming interface 604. In this embodiment, the tokenrequest includes a parameter indicating that the interval durationthreshold is 30 seconds by way of example, the token request alsoincludes an instruction to commit or rollback the data in the unit ofwork set automatically 30 seconds after initiating the unit of work set.The application programming interface 604 is connected to uniqueidentification service 608. At 610 the application programming interface604 requests a unique identification code from the unique identificationservice 608. The unique identification service 608 returns a uniqueidentification code at 612. At 614 the application programming interfacecreates a unit of work token including the parameters and the uniqueidentification code. At 616 the unit of work token is returned to theclient 602 and the connection is terminated.

At 618 the client 602 makes an insert, update, or delete request to theapplication programming interface and a connection is created. Therequest is received by the application programming interface 604 and theconnection is terminated at 620. At 622 the request and unit of worktoken are recorded in temporary storage located on the persistentstorage device 624. If the application programming interface determinesthat the duration of time since the token has been received has exceededa threshold, here 30 seconds, it may instruct the persistent storagesystem 624 to commit or rollback unit of work requests with the unit ofwork token at 626. In some embodiments, the requests are automaticallyrolled-back if the threshold is reached. In other embodiments the systemconsults an instruction defined in the token parameter to either commitor rollback the unit of work set or prompt the client to submit aninstruction. Other embodiments may determine whether to commit orrollback the set upon exceeding other threshold parameters, such as thenumber of records in the unit of work set.

If the set is not committed or rolled back at 626, the client 602 maysend, via the application programming interface 604, an instruction tocommit or rollback the unit of work set and the token for the unit ofwork at 628. At 630 the application processing device sends aninstruction to commit or rollback unit of work requests with the unit ofwork token.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the scope of thedisclosure. For example, the principles herein could be used innon-key/value type databases. Various modifications and changes may bemade to the principles described herein without following the exampleembodiments and applications illustrated and described herein, andwithout departing from the spirit and scope of the disclosure.

1. A data storage system comprising: one or more remotecomputer-readable storage mediums configured to form a non-persistentstateless connection with a client computer; one or more processorsassociated with the one or more remote computer-readable storagemediums; a database hosted on the one or more remote computer-readablestorage mediums; the one or more remote computer-readable storagemediums having instructions stored which, when executed by theprocessor, cause the one or more computer-readable storage mediums toperform actions comprising: generating a unit of work token containing aunique identification code and one or more parameters; recording theunit of work token in a unit of work repository; generating a unit ofwork set; associating the unit of work set with the unit of work token;providing the unit of work token to the client; receiving a databaserequest from the client, the database request including the unit of worktoken; identifying the associated unit of work set based on the unit ofwork token; recording the database requests in the unit of work set; andcommitting or rolling-back the database requests in the unit of work setbased on an instruction to commit or to rollback the unit of work set.2. The data storage system of claim 1, wherein the database is akey/value database.
 3. The data storage system of claim 2, wherein thedatabase includes a key store comprising of keys associated withrespective data location pointers.
 4. The data storage system of claim3, wherein the one or more database requests include the uniqueidentification code, the associated key, and a command.
 5. The datastorage system of claim 4, wherein the command includes commands to atleast one of update, insert, or delete data associated with the key. 6.The data storage system of claim 1, wherein the one or more parametersinclude a threshold and the instruction to commit or to rollback theunit of work set; and the one or more remote computer-readable storagemediums has additional instructions stored which, when executed by theprocessor, cause the one or more remote computer-readable storage mediumto perform actions comprising: sending the instruction to commit orrollback the unit of work set when the threshold is exceeded.
 7. Thedata storage system of claim 6, wherein the parameters are assigned adefault value.
 8. The data storage system of claim 6, wherein theparameters are defined by a user.
 9. The data storage system of claim 6,wherein the threshold is a number of records or a duration of time. 10.A computer-readable storage medium storing instructions which, whenexecuted by a computing device, cause the computing device to perform amethod comprising: generating a unit of work set with a uniqueidentification code; sending the unique identification code to a clientwith a non-persistent stateless connection with the computer-readablestorage medium; receiving two or more database requests having theunique identification code from two or more HTTP sessions; recording thetwo or more database requests in a unit of work set; and committing thetwo or more database requests in the unit of work set or rolling-backthe two or more database requests in the unit of work set after the unitof work set is closed.
 11. The computer-readable storage medium of claim10, storing additional instructions which, when executed by a computingdevice, cause the computing device to perform a method comprising:denying a user access to data subject to the two or more databaserequest.
 12. The computer-readable storage medium of claim 10, whereinthe two or more database requests are committed or rolled-back based ona user instruction.
 13. The computer-readable storage medium of claim10, further comprising: a key/value database; an application programminginterface; a unique identification service; and a unit of workrepository.
 14. A method for processing database requests on a databasehosted on a stateless non-persistent computing environment, the methodcomprising of: generating a unique identification code to identify aunit of work set; generating the unit of work set at a storage locationand assigning one or more parameters to the unit of work set; receiving,by a remote server, database requests from a client and recording thedatabase requests in the unit of work set; closing the unit of work setbased the one or more parameters assigned to the unit of work set; anddetermining whether to perform the database requests in the unit of workset on the database after the unit of work set is closed.
 15. The methodof claim 14, wherein the one or more parameters is whether to performthe database requests in the unit of work set on the database.
 16. Themethod of claim 14, wherein the unit of work set is closed after athreshold time.
 17. The method of claim 14, wherein the unit of work setis closed if it contains a threshold number of database requests. 18.The method of claim 14, wherein the one or more parameters indicateswhether a client accessing the remote server may view database requestsin the unit of work set.
 19. The method of claim 14, wherein thedatabase request includes inserting, updating, or deleting databaseentries.
 20. The method of claim 14, wherein the database is a key/valuedatabase.